Those hotkeys are already in use in chrome
For me they open downloads, and dev tools console respectively.

https://support.google.com/chrome/answer/157179?hl=en&co=GENIE.Platform%3DDesktop

Now, we don't need to add more hotkeys at all (I would actually prefer we don't). One person in the original issue only suggested it as a lesser alternative if we couldn't get scroll linking to work, but the other PR takes care of that.

Now, we don't need to add more hotkeys at all (I would actually prefer we don't). One person in the original issue only suggested it as a lesser alternative if we couldn't get scroll linking to work, but the other PR takes care of that.

As a primarily hot key user, I know I would use the keys more than the buttons and live scrolling would annoy the crap out of me.

Fair enough. Just didn't want to add a feature if nobody actually wanted it.

I think hotkeys for navigating the page is a good idea. And this counts as navigating the page (it is changing the view).

I do think we can remove hotkeys for many snippets (and I made most of those hot keys so no one should be offended). The snippet menus themselves should have better keyboard navigation (cough radix cough), but in the meantime if there is a snippet hot key that would be better used for something else, I think it’s fine to claim it.

I intend to work on snippet menu very soon, 1) to convert to function components and 2) look at keyboard navigation and/or radix.

I'm sorry but:

https://homebrewery.naturalcrit.com/share/1Em9UpHcoKws3xv65lWCRGzPDr3xPAWzvp9-Fp6cxI0Ac

Ctrl-M is used to input spans.

Usual problem with hotkeys, every damn program uses them, windows, chrome, HB...

CTRL+SHIFT+RIGHT moves the editor, on the left half of the screen
CTRL+SHIFT+LEFT moves the preview, on the right half of the screen

To me, this feels backwards - that it would be more intuitive if the operation were reversed.

This is, of course, a matter of opinion.

CTRL+SHIFT+RIGHT moves the editor, on the left half of the screen CTRL+SHIFT+LEFT moves the preview, on the right half of the screen

To me, this feels backwards - that it would be more intuitive if the operation were reversed.

I really don't have a strong opinion one way or the other.

Does anyone have strong feelings over which arrow should impact which direction?

@calculuschild @G-Ambatte @ericscheid @5e-Cleric

I would say the arrow should indicate the direction of info transfer. I.e. pointing right is sending the position from left to right.

With the :has() selector, or one of the other newer ones, could we style each pane based on which "scroll arrow" is being hovered?

This is kind of funky idea, but if a user is hovering the "scroll preview to match editor" button, the preview pane would show a faint, but visible, double-sided arrow overlaid on it. And vice versa.

Quick mockup, for hovering the "scroll preview to match editor":

I've spent about 0.5 seconds thinking of the css for this, but it seems like it should be possible (or maybe it's a JS thing). Maybe it even points which direction the pane will scroll....(but then you could have another argument about which way an arrow should point to indicate the page will scroll "up")

Obviously this doesn't solve the immediate question about which way arrows point, but I think it would make it very clear to the user what is about to happen, both on the 'first try' and every subsequent try.

Looks good. Gonna merge this.